Student venture management

ABSTRACT

A technique involves: receiving authentication information for a team leader at an authentication engine; storing a venture scholarship application data structure in a new applications data store; storing credentials of the team leader in association with the venture scholarship application data structure; building a student venture team at a venture scholar networking engine; storing credentials of members of the student venture team in association with the venture scholarship application data structure; allocating financial support associated with the venture scholarship after the venture scholarship is indicated to be eligible by an eligibility filtering engine; recording equity or an instrument convertible to equity in a student venture associated with the student venture team and the venture scholarship at a student venture fund operations engine; allocating equity or the instrument convertible to equity from the student venture to members working on the student venture as the student venture matures.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is a divisional of U.S. patent application Ser.No. 13/890,065 filed May 8, 2013, entitled “STUDENT VENTURE MANAGEMENT,”which is a divisional of U.S. Pat. No. 8,463,691 issued Jun. 11, 2013,entitled “STUDENT VENTURE MANAGEMENT,” which claims priority to U.S.Provisional Patent Application Ser. No. 60/999,238, filed Oct. 16, 2007,entitled “VENTURE CAPITAL TRANSACTION WITH A UNIVERSITY SCHOLARSHIP,”all of which are incorporated by reference.

BACKGROUND

A successful startup business venture is an aggregation of manyingredients, including an innovative business concept; entrepreneurialand management skills, knowledge, and experience; and capital funding.These elements generally are contributed by entrepreneurs, universities,and venture capital firms, respectively. Presently, a degree ofdisconnect exists between these actors, such that pooling theirrespective contributions to create and grow a successful startupbusiness venture is a common difficulty.

In some cases there will exist one actor or ingredient but neither ofthe other two. In other cases, for example, venture capital firms (VCs)and entrepreneurs interact, but there are no incentive structures orinstruments that benefit all actors in the VC, entrepreneur, anduniversity micro-economy. An entrepreneur, such as a young entrepreneuror a student entrepreneur, for example, may possess an innovative newbusiness idea, but typically will lack the business and managementskills and experience, as well as the capital funding, to pursue andtransform the business idea into a successful startup business venture.However, there is currently no successful structure to capture deal flowwith student entrepreneurs.

VCs, for their part, must invest in ventures that will yield highreturns, and often are too selective to invest in early startup businessventures. VCs with large funds cannot afford to touch smaller deals.Some may argue that early stage investors exist, but VCs do not investat a concept stage. Technically the earlier deals have even higheryields; the lack of interest has more to do with the higher risk indealing with younger, first-time university entrepreneurs and the factthat they have to deploy larger amounts of cash at a time due to theirfund size. This presents a serious disadvantage given that many newsuccessful companies are being formed by a young generation of CEOsduring or straight out of college. VCs lack early visibility into suchstartup business ventures and the ability to investigate and evaluatetheir potential for return. VCs therefore need stronger relationshipswith universities in order to gain access to this increasingly promisingbody of student entrepreneurs.

Universities, despite their contributing the ingredients of business andmanagement knowledge to a startup business venture to studententrepreneurs, fail to realize any part of the returns of a startupbusiness venture founded by its students. Currently, there may be somereturn on investment, realized by deploying capital to a VC asset classand waiting for a return to materialize in a VC's portfolio.

Specifically, university endowments grant scholarships that enablestudents to obtain an education at reduced or no cost. FIG. 1 depicts aconceptual diagram 100 of a prior art endowment grant process. Thediagram 100 includes a university endowment 102, an asset class 104, andcurrent expenses 106. In the example of FIG. 1, the university endowment102 invests (110) in the asset class 104. Typically, this involvesgiving money a VC asset and/or other assets. In the example of FIG. 1,the asset class 104 earns a return (112), which is given back to theuniversity endowment 102.

In the example of FIG. 1, after the university endowment 102 receivesthe return, the university endowment can pay (114) current expenses 106.However, at this point, there is no return (116) on the payment ofcurrent expenses 106.

A university endowment may have scholarships that constitute an expenseor suck cost that bears no return to the university, except should analum make a donation to the university endowment at some indeterminablefuture point in time. Even in such a case, to trace the donationdirectly back to the scholarship would be highly speculative, and thusfuture return on a scholarship is difficult if not impossible tomeasure. In terms, then, of realizing returns on a startup businessventure to which a university has directly contributed, the universityis cut out of the loop. Of course, the university may indirectly get areturn by investing in VC assets. However, since no one really investsin university entrepreneurs, this can be construed to mean that theuniversity is, for all practical purposes, cut out of the loop entirely.

A return on the payment of current expenses would be similar to earninga return for paying bills, or a bill collector marking down that youhave paid and invests in the stock market for you. Since this seems likea natural state of affairs, no effort has been made to change the statusquo. The foregoing examples of the related art and limitations relatedtherewith are intended to be illustrative and not exclusive. Otherlimitations of the related art will become apparent upon a reading ofthe specification and a study of the drawings.

The foregoing examples of the related art and limitations relatedtherewith are intended to be illustrative and not exclusive. Otherlimitations of the related art will become apparent upon a reading ofthe specification and a study of the drawings.

SUMMARY

The following examples and aspects thereof are described and illustratedin conjunction with systems, tools, and methods that are meant to beexemplary and illustrative, not limiting in scope. In various examples,one or more of the above-described problems have been reduced oreliminated, while other examples are directed to other improvements.

A technique for implementing a student venture involves providing anactual cost commitment and investing a retail value of the actual costcommitment to a student venture, and receiving a return on the retailvalue and a return on actual cost that is equal to the return on theretail value minus the actual cost commitment. A system constructedaccording to the technique may include an investment decision engine, aportfolio management engine, and a venture scholar fund operationsengine. The system may further include, for example, an authenticationengine and a public information engine.

BRIEF DESCRIPTION OF THE DRAWINGS

The following figures are intended to illustrate, by way of example butnot limitation, aspects of techniques described in this paper.

FIG. 1 depicts a conceptual diagram of an example of a prior artendowment grant process.

FIG. 2 depicts a conceptual diagram of an example of a universityendowment student venture transaction.

FIG. 3 depicts a flowchart of an example of a method of investing in astudent venture.

FIG. 4 depicts a flowchart of an example of a method of participating ina student venture.

FIG. 5 depicts a flowchart of an example of a method of student venturemanagement.

FIG. 6 depicts a flowchart of an example of an investment decisionmethod.

FIG. 7 depicts a flowchart of an example of a student ventureapplication management method.

FIG. 8 depicts a flowchart of an example of a collaborative studentventure ranking method.

FIG. 9 depicts a flowchart of an example of an abbreviated due diligencemethod.

FIG. 10 depicts a flowchart of an example of a student venture termsheetmanagement method.

FIG. 11 depicts a flowchart of an example of a termsheet modificationmethod.

FIG. 12 depicts a flowchart of a venture scholar networking method.

FIG. 13 depicts a flowchart of a venture scholar portfolio managementmethod.

FIG. 14 depicts a flowchart of a student venture fund operations method.

DETAILED DESCRIPTION

In the following description, several specific details are presented toprovide a thorough understanding. One skilled in the relevant art willrecognize, however, that the concepts and techniques disclosed hereincan be practiced without one or more of the specific details, or incombination with other components, etc. In other instances, well-knownimplementations or operations are not shown or described in detail toavoid obscuring aspects of various examples disclosed herein.

FIG. 2 depicts a conceptual diagram 200 of an example of a universityendowment student venture transaction. The diagram 200 includes auniversity endowment 202 and a student venture 204.

In the example of FIG. 2, the university endowment 202 provides anactual cost commitment (C) 210, where C represents actual cost to theuniversity. However, the face or retail investment value of scholarshipcommitments will be the actual amount charged to students. This isrepresented in the diagram 200 as a retail value of investment (R) 212,where R represents the retail value of the scholarship commitments. Asis apparent in the diagram 200, the value of the investment is higherthan the actual commitment. So, the university endowment 202, in asense, has already earned a return R−C=P, where P represents thepremium. This assumes the retail value exceeds the actual cost ofproviding an education to a student, such that the university has aprofit margin on the student. However, even if the actual value exceedsthe retail value, it may be possible to make up for the reducedinvestment value through the student venture 204.

When providing capital commitments in the form of scholarshipcommitments, the university need only commit to providing the actualcost of education per student. However, the advantageous perception willbe that it has contributed scholarship commitments worth the apparentretail value of its educational services. The university thuseffectively also earns a return based on its profit margin for providingeducational services. This is particularly advantageous for prestigiousand selective institutions that can command a price premium for theireducational services.

Following the initial investment in the student venture 204, assumingeven moderate success, a return is expected. In the example of FIG. 2,the return on retail investment (Rn) 214 is a multiple, n, times theretail value of investment. The return on actual cost (Rn−C) 216, is thereturn on investment from the perspective of the university endowment202. In other words, the investment in the student venture is the retailcost of the education, while the return on the investment is a multipleof the retail value of the education less the actual cost. That meanseven at 1×, just returning a “capital equivalent,” the universityendowment 202 has already earned a premium R−C=P.

FIG. 3 depicts a flowchart 300 of an example of a method of investing ina student venture. The method is organized as a sequence of modules inthe flowchart 300. However, it should be understood that these andmodules associated with other processes and methods described herein maybe reordered for parallel execution or into different sequences ofmodules.

In the example of FIG. 3, the flowchart 300 starts at module 302 withproviding a capital commitment to a student venture. The capitalcommitment may come in the form of cash or a cash equivalent, and maycome from any applicable entity, such as a VC, LP, individual, or otherentity. The capital commitment may include a scholarship. A scholarshipthat is provided in association with a student venture is referred to inthis paper as a “venture scholarship.”

In the example of FIG. 3, the flowchart 300 continues to module 304 withtransferring the capital commitment to the student venture. In this way,the capital commitment serves as an investment in the student venture.

In the example of FIG. 3, the flowchart 300 continues to module 306 withdisbursing the capital commitment to a student associated with thestudent venture. The capital commitment may be disbursed to the studenton a predetermined schedule, based upon milestones achieved in thestudent venture, or upon other predetermined or agreed-upon criteria.The student venture is in essence a startup company run by universitystudents. However, it should be noted that the student venture need notbe a formal legal entity.

In the example of FIG. 3, the flowchart 300 continues to module 308 withproviding equity or an instrument convertible to equity from the studentventure. Like traditional venture capital transactions, in exchange forthe capital commitment, a VC may receive equity or an instrumentconvertible to equity from the student venture. Instruments convertibleto equity, such as warrants and convertible notes, reflect acontemplation of student ventures that do not exist as formal legalentities and that have no present equity to grant to the VC. However,this is not the only concern. It is common practice to issue convertibledebt or a bridge note for early stage companies to avoid the need tocontemplate a valuation at such an early stage. The convertible orbridge note converts based on a subsequent round of institutionalinvestment in the venture. This way the later stage VC set the valuationand the early stage entity gets a discount to that based on the terms ofthe note. This happens frequently in angel investing becauseentrepreneurs feel it is more accurate to have VCs price a round insteadof angels, but angels should get some reward since they invested earlierthan a VC would.

Using techniques described in this paper, VC firms may be given constantand early visibility and access to student entrepreneurs, a promisingnew source of deal flow. Additionally, investment costs may be keptrelatively low. Earlier stage is typically more risky and more rewardingfor VC firms. Advantageously, risk reduction or rather risk compensationcan come from tax benefits over traditional VC. This makes it easier toget endowment funds invested (a right typically only reserved for thetop tier firms). So one can participate at higher risk/reward venture atlower adjusted cost. For example, while still gaining equity in aninvestment as a traditional VC transaction, VCs can pay a discountedrate for skilled labor to run the venture, as generally it is cheaper topay for a student's education than a skilled professional's salary inthe work force.

FIG. 4 depicts a flowchart 400 of an example of a method ofparticipating in a student venture. In the example of FIG. 4, theflowchart 400 starts at module 401 with forming a student venture team.This can include matching with teammates using a venture scholar network(e.g., an online matchmaker). The team and/or team members may or maynot have patentable inventions. Depending upon the implementation orconfiguration, there may be an option to file for patent protection in acountry of origin, start a company in the country of origin, and assignpatent rights to that company.

In the example of FIG. 4, the flowchart 400 continues to module 402 withapplying for a venture scholarship. A student (or prospective student)may apply for a venture scholarship by, for example, submitting aproposal or a business plan for a student venture. Unlike traditionalscholarships, the venture scholarship may or may not be based uponfinancial need or academic performance, but rather on the businessmerits of a proposal for the student venture. If the venture scholarshipapplication is accepted, team members can negotiate for an equityexchange for capital in the student venture or, if patent rights wereassigned to a company in a team member's country of origin, trade equityin the company for capital in the student venture. At some point before,during, or after the application process, the student venture can bematched with one or more mentors, and milestones can be developed withthe help of the mentor(s) and partners in the student venture and/orventure fund.

In the example of FIG. 4, the flowchart 400 continues to module 404 withreceiving financial support associated with the venture scholarship. Ifthe student's proposal for a student venture is accepted, the studentmay receive financial support, for example, in the form of a venturescholarship. The venture scholarship may cover the student's tuition,room and board, or other fees, and allocations for venture expenses notcovered through a venture lab. Venture lab is a way to, for example,spread fixed cost across many student ventures. Thus, the studentventure can be used to leverage space in a venture lab and to enable theteam members to engage in entrepreneurship curriculum and boot camps.Additional funds outside of the venture scholarship itself may be usedto run the student venture, such as, by way of example but notlimitation, another venture.

In the example of FIG. 4, the flowchart 400 continues to module 406 withgranting equity or an instrument convertible to equity in a studentventure associated with the venture scholarship. In exchange for theventure scholarship, the student grants equity or an instrumentconvertible to equity in the student venture to a VC or other investor.In addition, the student may or may not have an initial amount of equityin the student venture. The student venture need not be a legal entity.

In the example of FIG. 4, the flowchart 400 continues to module 408 withworking for the student venture. The student venture is similar to otherbusiness ventures except as described in this paper. One specificdifference from other business ventures is that student ventures “hire”students instead of employees. Thus, in addition to granting equity inthe student venture, the student must also work for the student venturewhile attending the university, much like an internship or part-timejob. The student venture matures by getting customers, selling products,attracting users, etc.

In the example of FIG. 4, the flowchart 400 continues to module 410 withreceiving equity or an instrument convertible to equity from the studentventure. The student's receipt of equity or an instrument convertible toequity in the student venture may be contingent upon the studentsatisfying specified milestones, or according to some other vestingschedule. If the student venture is within allowable incubation timesand acceptable milestone ranges, milestones can be further developed asthe student venture matures. If not, the team members can potentiallytake on funding from other VCs. If the student venture is successfulafter the allowable incubation time, it may be possible to reach aliquidity event. If not, the team members can either re-apply with a newstudent venture or quit.

The principles described thus far with reference to FIGS. 2-4 can beimplemented in engines as illustrated in FIG. 5. FIG. 5 depicts aflowchart 500 of an example of a method of student venture management.In the example of FIG. 5, the flowchart 500 starts with anauthentication engine 502. The authentication engine 502 can beimplemented as hardware and/or as software implemented in hardware. Thetype of authentication that may be performed can establish what otherengines may be accessible to a particular user.

As used in this paper, an engine is a combination of instructions and aprocessor configured to execute the instructions. Any applicable knownor convenient processor technology can be used. A special-purpose engineprocessor can include a processor with relevant instructions tomanipulate data in a manner that is appropriate to the techniquesdescribed in this paper. In a typical implementation, an engine will beassociated with at least some instructions that are executed by theprocessor, though it is possible that the processor would be implicit inthat the instructions are, for example, implemented in a solid-statedevice without a conventional processor or executables stored in memory.More likely, a processor is specially configured to carry out tasksassociated with the relevant engine. Configuration of the processor canoccur at the time of manufacture, later in the form of “read-only”instructions executable by the processor and/or dynamically in the formof software loaded into appropriate hardware registers for execution bythe processor. A processor is frequently shared with instruction setsfrom various programs, some of which may not be related to the relevantengine, and instructions associated with the relevant engine, other thanperhaps the most trivial, typically cannot be kept in hardware registersconcurrently. Sometimes, due to the size of the instruction set and/orthe memory load, instructions associated with the relevant engine cannoteven be kept in cache or memory (e.g., RAM), and must instead be kept innon-volatile storage (e.g., a hard disk).

In the example of FIG. 5, the flowchart 500 continues to decision point504 where it is determined whether there is a pending investmentdecision. If it is determined that there is a pending investmentdecision (504-Y), then the flowchart 500 continues to an investmentdecision engine 506. The investment decision engine is described in moredetail with reference to FIGS. 6-11. The flowchart 500 then returns todecision point 504 to determine whether there is another pendinginvestment decision.

If it is determined that there is not a pending investment decision(504-N), then the flowchart 500 continues to either the venture scholarnetworking engine 508, a venture scholar portfolio management engine510, or a student venture fund operations engine 512. The venturescholar networking engine 508 is described in more detail with referenceto FIG. 12. The venture scholar portfolio management engine 510 isdescribed in more detail with reference to FIG. 13. The student venturefund operations engine 512 is described in more detail with reference toFIGS. 14 and 15.

FIG. 6 depicts a flowchart 600 of an example of an investment decisionmethod. In the example of FIG. 6, the flowchart 600 starts with astudent venture application management engine 602, which is described inmore detail with reference to FIG. 7.

In the example of FIG. 6, the flowchart 600 continues with acollaborative student venture ranking engine 604, which is described inmore detail with reference to FIG. 8.

In the example of FIG. 6, the flowchart 600 continues to decision point606 where it is determined whether there are more rankings to perform.If it is determined that there are more rankings to perform (606-Y),then the flowchart 600 returns to the student venture applicationmanagement engine 602 and continues as described above. If, on the otherhand, it is determined that there are no more rankings to perform(606-N), then the flowchart 600 continues with an abbreviated duediligence engine 608, which is described in more detail with referenceto FIG. 9.

In the example of FIG. 6, the flowchart 600 continues to decision point610 where it is determined whether it is time to consider a termsheet.If it is determined that it is not time to consider a termsheet (610-N),then the flowchart 600 returns to the student venture applicationmanagement engine 602 and continues as described above.

If, on the other hand, it is determined that it is time to consider atermsheet (610-Y), then the flowchart 600 continues with a studentventure termsheet management engine 612, which is described in moredetail with reference to FIG. 10. The student venture termsheetmanagement engine 612 may generate a termsheet or it may fail togenerate a termsheet (e.g., if relevant parties do not agree on theterms). It is typically “time to consider a termsheet” when a VC funddecides to issue a termsheet.

Although there is no end to the flowchart 600 as depicted in the exampleof FIG. 6, it is, of course, possible to conclude a given transactionand finalize a termsheet. In any case, in the example of FIG. 6, theflowchart 600 returns to the student venture application managementengine 602 to modify the current transaction or to start a differenttransaction.

FIG. 7 depicts a flowchart 700 of an example of a student ventureapplication management method. Prior to the start of the flowchart 700,depending upon implementation and/or embodiment, a team leader may berequired to authenticate (see, e.g., the authentication engine 502 inFIG. 5). For example, it may be desirable to include a venture scholarapplicant registration, authentication, and login.

In the example of FIG. 7, the flowchart 700 starts at module 702 withcreating credentials for a team member. Credentials can include, forexample, login and authentication credentials. The first team member forwhich credentials are created may be referred to as the team leader,though a distinction between the team leader and other team members mayor may not be made once the team is assembled. The credentials can bestored as part of a venture scholarship application, as indicated by thedashed arrow from the module 702. It may be noted that where the teamleader is required to authenticate before the flowchart 700 starts, theteam leader can either use credentials that are at least partiallydifferent from those created at the module 702, or the module 702 can beskipped for the team leader if the team leader has sufficientcredentials that would have been created at the module 702.

In the example of FIG. 7, the flowchart 700 includes a dashed arrow fromthe module 702 to a venture scholarship application 704. The dashedarrow is intended to indicate that data input and/or generated at themodule 702 becomes part of the venture scholarship application 704. Thedashed arrow is not intended to indicate an order of flow in theflowchart 700, but rather act as a conceptual indicator of the dataknown at a given point. The venture scholarship application 704 mayexist as a data structure in memory (or a buffer, cache, register, orother applicable known or convenient storage location), a combination ofassociated data structures in memory, or even as a combination ofunrelated data structures that are later associated. The duration withwhich the venture scholarship application 704 exists in memory islargely irrelevant. For example, data associated with the venturescholarship application 704 could be relatively quickly written tonon-volatile storage as it is received, the venture scholarshipapplication 704 could be built completely in memory before being storedin non-volatile storage, or somewhere in between.

In the example of FIG. 7, the flowchart 700 continues to decision point706 where it is determined whether there are more members to add to theventure scholarship team. If it is determined that there are moremembers to add to the venture scholarship team (706-Y), then theflowchart 700 continues to module 708 with inviting the team member intothe system. The invitation need not be a formal invitation, but ratheris any known or convenient mechanism for prompting a user to providecredentials. The module 708 could even be skipped if the system iscapable of acquiring appropriate data without inviting the team member.Then the flowchart 700 continues to the module 702 and continues asdescribed previously for the current team member.

If, on the other hand, it is determined that there are no more membersto add to the venture scholarship team (706-N), then the flowchart 700continues to module 710 with inputting profile information for teammembers. The dashed arrow from the module 710 to the venture scholarshipapplication 704 is intended to indicate that data input and/or generatedat the module 710 becomes part of the venture scholarship application704.

Profile information for team members can include, for example:

-   -   1. Name/Age/Sex;    -   2. Social Security Number;    -   3. GPA (general and in major);    -   4. Major;    -   5. Output from background check;    -   6. Psychographic analysis (like MBTI typing);    -   7. References (professor and previous job);    -   8. Job experience (scored as it relates to a proposed venture);    -   9. Mentor preferences;    -   10. Other profile information.

There may also be collective profile information, which can include, forexample:

-   -   1. Missing roles;    -   2. Collective psychographic profile (possibly indicating        potential team dysfunctionality);    -   3. Collective skill set (should be appropriate for the proposed        venture);    -   4. Mentor preferences (potentially offsetting team's collective        weaknesses).

In the example of FIG. 7, the flowchart 700 continues to module 712 withcompleting a venture profile/questionnaire. The dashed arrow from themodule 712 to the venture scholarship application 704 is intended toindicate that data input and/or generated at the module 712 becomes partof the venture scholarship application 704. The dashed arrow from theventure scholarship application 704 to a new applications database 714is intended to indicate that the venture scholarship application 704 isstored as an entry in the new applications database 714. It may be notedthat the data could have been stored in the new applications database714 more or less as it was received (e.g., after creating credentialsfor a team member at the module 702, the credentials could have beenstored in the new applications database 714).

The new applications database 714 can be implemented as hardware and/orsoftware implemented in hardware. As used in this paper, a database caninclude a traditional database, a table, an array, or any otherapplicable data structure capable of storing data in a manner that is atleast somewhat convenient to a user of the database. A database canoptionally include a database interface that can be implemented in wholeor in part on the hardware device on which data of the database isstored, or in whole or in part on a device that is accessing the data.As used in this paper, a database can be a centralized repository (e.g.,a device that stores all of the data of the database) or a distributedrepository (e.g., multiple devices, each storing a portion of thedatabase). Data can be stored in any applicable memory, includingnon-volatile storage, volatile storage (e.g., random access memory(RAM)), cache, or registers. Reading and writing data requires aprocessor, though any applicable known or convenient processortechnology can be used. A special-purpose database processor can includea processor with relevant instructions, whether stored in hardware or insoftware implemented in hardware, to read and write data in a mannerthat is appropriate to the techniques described in this paper.

The new applications database 714 includes entries, such as databaserecords, table elements, array elements, or any other applicableelements that can be part of a venture scholarship application, alongwith associated data, if applicable. As used in this paper, it isunderstood that some types of entries in databases (e.g., objects,arrays, etc.) can have sub-entries while other types of entries (e.g.,constants) may not have sub-entries. It can be advantageous to breakdown entries into sub-entries, such as fields, or any other applicableelements.

In the example of FIG. 7, the flowchart 700 continues to an eligibilityfiltering engine 716. The dashed arrow from the new applicationsdatabase 714 to the eligibility filtering engine 716 is intended toindicate that the eligibility filtering engine 716 considers the venturescholarship application 704 (and perhaps other applications). The dashedarrow from the eligibility filtering engine 716 to a filteredapplication database 718 is intended to indicate that eligibleapplications are stored in the filtered applications database 718. It isalso possible to implement the eligibility filtering engine 716 suchthat it deletes non-eligible entries from the new applications database714 (not shown), or perhaps this could be taken care of by markingnon-eligible entries for deletion and using a periodic (e.g., deletemarked entries annually after a review, or delete the entire newapplications database 714 after the student body is selected to preparefor a new round of admissions) or occasional (e.g., after anarbitrarily-timed review of non-eligible entries) clean-up routine.

Eligibility requirements for a team can include, for example:

-   -   1. The team member must be a matriculating student earning        either a master's or a PhD degree in engineering or earning a        MBA with an undergraduate engineering degree.    -   2. The team member must take or have taken certain classes or        met other curriculum-related requirements.    -   3. The team member must have a minimum GPA.    -   4. The team member cannot have a job while in the program.    -   5. The team member must have the unrestricted right to work in        the U.S. with company sponsorship, unless there is a legal        work-around, one of which is discussed later in this paper.    -   6. The team must include two to four members.    -   7. The business idea cannot be related to any master's thesis or        any school-owned idea.    -   8. The business idea must be in a hot investment space for the        investment horizon.

These “sector requirements” can change based upon a general portfoliomakeup, expertise of partners, investment market conditions, etc. Theseeligibility requirements can change over time, and they can be removedor new ones added. Requirements can vary depending upon otherqualifications. For example, GPA requirements might be lower if a teammember has certain work experience.

It should be noted that the new applications database 714 and thefiltered applications database 718 are conceptual. For example, theeligibility filtering engine 718 might simply check an eligibility fieldassociated with the venture scholarship application 704 in what might beconsidered a single database, thereby conceptually “adding” an entryassociated with the venture scholarship application 704 to the filteredapplications database 718 and “removing” the entry from the newapplications database 714. The databases could also have characteristicsthat would cause some of skill in the relevant art to consider them“separate” databases. The actual configuration is not critical, though,due to the nature of venture scholarships, meeting eligibilityrequirements (e.g., to receive a scholarship, a person must be astudent) may be deemed an important consideration. It is likely thatthose who participate in collaborative venture ranking would find itless than useful to be given the opportunity to consider studentventures associated with non-eligible team members. Conceivably,depending upon the implementation and/or configuration, if an entryassociated with the venture scholarship application 704 is associatedwith at least one eligible team member, the application may or may notbe added to the filtered applications database 716.

FIG. 8 depicts a flowchart 800 of an example of a collaborative studentventure ranking method, such as could be implemented by a collaborativestudent venture ranking engine. In the example of FIG. 8, the flowchart800 starts at authentication engine 802. The authentication engine 802is responsible for largely configuration-related procedures that ensureonly appropriately qualified entrepreneurs can submit a business plan(see, e.g., FIG. 7) and only appropriately qualified partners and/oradvisors can submit a venture submission query 804. The authenticationengine 802 can, for example, register, authenticate, verifyusername/password, etc. The authentication engine 802 can facilitatesubmission of the business plan from entrepreneurs to create a filteredapplications database 806 (see, e.g., FIG. 7). The authentication engine802 can facilitate submission of the venture submission query 804 to thesystem for the purpose of querying the filtered applications database806.

In the example of FIG. 8, the flowchart 800 continues to a web serverand backend controller 808. The web server and backend controller 808can be implemented as hardware and/or software implemented in hardware.As used in this paper, a server can refer to a process running on acomputing device, or to the computing device itself. In the latter case,the computing device can have multiple distinct server processes runningsimultaneously, but it should be clear from context which server processis being discussed at a given time. To be useful, a server is coupled toa client such that communication is facilitated between the server andthe client. As used in this paper, the term server may or may not referto a web server. A web server is configured to operate with theprotocols of the World Wide Web. Optionally, a web server can be part ofan Internet Service Provider (ISP) system that provides access to theInternet for client systems.

As is known to those of skill in the relevant art, a server typicallyinteracts with a client (not shown in FIG. 8). The client is associatedwith an entrepreneur, partner, advisor, or other party, and facilitatesinteraction with the server. The client can be implemented as hardwareand/or software implemented in hardware. As used in this paper, a clientcan refer to a process running on a computing device, or to thecomputing device itself. In the latter case, the computing device canhave multiple distinct client processes running simultaneously, but itshould be clear from context which client process is being discussed ata given time. To be useful, a client is coupled to a server such thatcommunication is facilitated between the server and the client.

In the example of FIG. 8, the flowchart 800 continues to the databaseinterface engine 810. The database interface engine 810 may or may notinclude a traditional database interface (e.g., an Oracle® databaseinterface), depending upon the implementation. The database interfaceengine 810 stores an entry associated with the business plan in thefiltered applications database 806 (see, e.g., FIG. 7). The databaseinterface engine 810 can also query the filtered applications database806 using the venture submission query 804, or data associated with theventure submission query 804. The results of the query are provided in aquery returned submission 812.

Depending upon the implementation, the database interface engine 810 canperform applicable procedures that make the data in the filteredapplications database 806 more useful to users of the system. This caninclude filtering entries according to certain criteria, tagging data,performing statistical analysis, and other activities that can occur inthe background according to periodic or spontaneous procedures, or uponreceipt of new data or queries. The database interface engine 810 canstore queries, such as the venture submission query 804 or dataassociated with the venture submission query 804, for later use. Forexample, a partner might want to select a deal from a previous query atany point during a deliberation process. The database interface engine810 may also be capable of removing entries if, by way of example butnot limitation, scores associated with the entry are too low.

In the example of FIG. 8, the flowchart 800 continues to deal scoringengine 814. Scoring may be according to various criteria, such as, byway of example but not limitation, business concept of submission,market for submission, intellectual property fences, demonstratedcustomer acceptance, competition strength, capital requirements,perceived risks, magnitude of uncertainty, team strength, venturestrategy, perceived exit potential, time to market, other attributes.Scores can include annotations and notes, as well. Users of the system,typically non-partners, may also answer questionnaires aboutapplications, which can be used to help score student ventureapplications (see, e.g., FIG. 9 for an example of a questionnairesdatabase). It may be desirable to include a mechanism to verify with aparty that they submitted a score or answers to a questionnaire, and tocertify truthfulness. The scoring is then associated with the relevantfiltered applications database 806 entry, as is indicated in the exampleof FIG. 8 by the dashed line from the deal scoring engine 814 to thefiltered applications database 806. Partners may later update scoresusing the answers provided in questionnaires, changing the weightassociated with questions in the questionnaires, considering comments,or according to other criteria.

FIG. 9 depicts a flowchart 900 of an example of an abbreviated duediligence method, such as could be implemented by an abbreviated duediligence engine (see, e.g., FIG. 6). Advantageously, due diligence canbe abbreviated when using the techniques described in this paperbecause, for example, venture scholars are already vetted by auniversity in accordance with their admissions policy.

In the example of FIG. 9, the flowchart 900 starts at authenticationengine 902. The authentication engine 902 is responsible for largelyconfiguration-related procedures that ensure only partners andappropriately qualified invitees can select deals from a group ofstudent venture applications. Certain procedures, such as creating,editing, or removing questionnaires may only be applicable to partners;so the authentication engine 902 may authenticate invitees for only asubset of the engines described in the example of FIG. 9. Theauthentication engine 902 can, for example, register, authenticate,verify username/password, etc.

In the example of FIG. 9, the flowchart 900 continues to decision point904 where it is determined whether an authenticated party is a partner.If it is determined that the authenticated party is a partner (904-Y),then the flowchart 900 continues to decision point 906 where it isdetermined whether the partner wishes to create, edit, or delete aquestionnaire. If it is determined that the partner wishes to create,edit, or delete a questionnaire (906-Y), then the flowchart 900continues to a questionnaire editing engine 908. The questionnaireediting engine 908 facilitates creation of a questionnaire, includinggiving a name to the questionnaire, adding a question, setting questionattributes, such as whether the question is required or optional, hasassociated attachments (such as data that is useful for review whenanswering the question), text constraints, and weighting the questionfor the purpose of setting scores in, for example, a collaborativestudent venture ranking engine (see, e.g., FIG. 8). The questionnairecan be added to a questionnaires database 910. The questionnaire editingengine 908 also facilitates editing a questionnaire, including adding,editing, or removing questions, changing question attributes. Thequestionnaire engine 908 also facilitates removing a questionnaire fromthe questionnaires database 910.

In the example of FIG. 9, after the a questionnaire is added, edited, orremoved, the flowchart 900 returns to decision point 906, where it isrepeatedly determined whether the partner wishes to create, edit, ordelete a questionnaire until it is determined that the partner does notwish to create, edit, or delete a questionnaire (906-N), at which pointthe flowchart 900 continues to invitation engine 912. The invitationengine 912 facilitates the invitation of entrepreneurs, references forteam members, or other parties by partners. It may be noted that in someembodiments, parties could be invited by other parties (not shown). Forexample, a first entrepreneur could invite a second entrepreneur. Forthe purposes of this example, the partner may invite zero or moreparties at the invitation engine 912. Since it is possible to invitezero parties when carrying out the method, the invitation engine 912 isindicated to be optional. However, it should be noted that the system ismost useful if parties other than partners have access to certainaspects of the system. So some type of invitation (whether explicit orimplicit, or push-type or pull-type) would be desirable.

In the example of FIG. 9, the flowchart 900 continues to the dealselection engine 914, which is described shortly. Returning once againto decision point 904, if it is determined that the authenticated partyis not a partner (904-N), then the flowchart 900 continues to dealfiltering engine 916. The deal filtering engine 916 filters studentventure applications to which, for example, a non-partner invitee hasaccess. The results of the deal filtering engine 916 may also reduceaccess to certain engines in the system, the specifics which may varydepending upon the implementation, configuration, embodiment, or “level”of authentication for a given party.

In the example of FIG. 9, the flowchart 900 continues to the dealselection engine 914. The deal selection engine 914 facilitatesselection of a deal from a filtered applications database 918. The dealfiltering engine 916, when applicable, can limit the deals that can beselected in this way, as described previously. Querying the filteredapplications database 918 can be accomplished through a known orconvenient system, such as a server and a client. The party conductingthe query may receive a list of deals in, for example, a deal listdashboard (not shown), from which a specific deal can be selected, or,depending upon implementation, configuration, authorization, and/orembodiment, a suite of deals can be considered at once.

In the example of FIG. 9, the flowchart 900 continues to comments engine920. The comments engine facilitates the reading and writing of commentsin association with student venture applications, questionnaires, orother parts of the system. The reading or writing of comments may berestricted based upon whether a party is a partner or non-partner (andby that amount of access permitted for a non-partner, if applicable).Different users may have different authorizations to read comments, evenfor student venture applications that they can access, and may havedifferent “places” in the applications where comments can be written.For example, some users may be able to add general comments about adeal, comments about questionnaire-submitted answers, comments tosubmitted documents, comments to collaborative ranking scores, commentsto other comments, or any other applicable comment. Comments can bestored in a due diligence comments database 922, as is depicted in theexample of FIG. 9 by the dashed arrow from the comments engine 920 tothe due diligence comments database 922. The entries of the duediligence comments database 922 can be a distinct database (whether atraditional database or not), comments can be stored in association withthe relevant item (e.g., student venture application, questionnaire,etc.), or all relevant due diligence data can be thought of as acomprehensive due diligence database (not shown) useful when selectingstudent ventures in which to invest.

FIG. 10 depicts a flowchart 1000 of an example of a student venturetermsheet management method, such as could be implemented by a studentventure termsheet management engine (see, e.g., FIG. 6). In the exampleof FIG. 10, the flowchart 1000 starts at authentication engine 1002. Theauthentication engine 1002 is responsible for largelyconfiguration-related procedures that ensure only partners andappropriately qualified student venture teams, entrepreneurs, lawyers,etc. can facilitate in the generation of a termsheet associated with astudent venture. Certain procedures, such as creating, editing, orremoving termsheet templates may only be applicable to partners; so theauthentication engine 1002 may authenticate other users for only asubset of the engines described in the example of FIG. 10. Theauthentication engine 1002 can, for example, register, authenticate,verify username/password, etc.

In the example of FIG. 10, the flowchart 1000 continues to a termsheetmodification engine 1004. The termsheet modification engine 1004 isdescribed in more detail in the example of FIG. 11. The termsheetmodification engine 1004 facilitates the creation of a termsheet 1006,which can be started from scratch—or from a template from a templatesdatabase (not shown)—and built using terms from a terms database (notshown) and rules from a rules database (not shown), and which is storedin a termsheets database 1008.

In the example of FIG. 10, the flowchart 1000 continues to decisionpoint 1010 where it is determined whether to edit terms. If it isdetermined that terms are to be edited (1010-Y), then the flowchart 1000continues to the termsheet modification engine 1004, as describedpreviously. If, on the other hand, it is determined that the terms arenot to be edited, then the flowchart 1000 continues to approvalauthorization engine 1012. The approval authorization engine 1012 cansubmit a termsheet or relevant data to a partner for comments and/orauthorization for approval. The approval authorization engine 1012 canalso submit the termsheet to a lawyer for comments and/or authorizationfor approval. If approval is authorized by the partner (and otherpartners, if applicable) and the lawyer (and other lawyers, ifapplicable), then the termsheet can be signed by a student venture teamand an entrepreneur, if they can agree to the terms of the termsheet.

In the example of FIG. 10, the flowchart 1000 continues to decisionpoint 1014 where it is determined whether approval is authorized. Ifapproval is not authorized (1014-N), then the flowchart 1000 continuesto decision point 1016 where it is determined whether to continue. If itis determined not to continue (1016-N), then the flowchart 1000 endswith a failure to create a timesheet that is acceptable. If, on theother hand, it is determined to continue (1016-Y), then the flowchart1000 returns to decision point 1010 and continues as describedpreviously. Presumably, if approval was not authorized (1014-N), but itis determined that the process should continue (1016-Y), then it will bedetermined that the terms need to be edited (1010-Y). However, it ispossible that approval is not authorized due to factors outside of thescope of the flowchart 1000; when those factors change, approval may beauthorized.

Returning once again to decision point 1014, if it is determined thatapproval is authorized (1014-Y), then the flowchart 1000 continues to atermsheet negotiation engine 1018. The termsheet negotiation engine 1018facilitates negotiations between an entrepreneur interested in a studentventure and the student venture team associated with the studentventure. Either party may be assisted by other parties, of course.

In the example of FIG. 10, the flowchart 1000 continues to decisionpoint 1020 where it is determined whether the parties accept the termsof the termsheet. If it is determined that the parties do not accept theterms of the termsheet (1020-N), then the flowchart 1000 returns todecision point 1016 and continues as described previously. A decision tocontinue may mean that the parties are interested in continuing thenegotiations, while a decision not to continue may mean thatnegotiations have ended in failure. If, on the other hand, it isdetermined that the parties accept the terms of the termsheet (1020-Y),then the flowchart 1000 continues to a student venture acceptance engine1022, where the termsheet is signed and student venture data is storedin a venture portfolios database 1024. At this point, the flowchart 1000ends.

FIG. 11 depicts a flowchart 1100 of an example of a termsheetmodification method, such as could be implemented by a termsheetmodification engine (see, e.g., FIG. 10). In the example of FIG. 11, theflowchart 1100 starts at authentication engine 1102. The authenticationengine 1102 is responsible for largely configuration-related proceduresthat ensure only partners and appropriately qualified entrepreneurs,VCs, lawyers, etc. can facilitate in the generation of a termsheetassociated with a student venture. Certain procedures, such as creating,editing, or removing termsheet templates may only be applicable to, forexample, partners and VCs; so the authentication engine 1102 mayauthenticate other users for only a subset of the engines described inthe example of FIG. 11. The authentication engine 1102 can, for example,register, authenticate, verify username/password, etc.

In the example of FIG. 11, the flowchart 1100 continues to decisionpoint 1104 where it is determined whether to manage a termsheettemplate. If it is determined to manage a termsheet template (1104-Y),then the flowchart 1100 continues to termsheet templates managementengine 1106. The termsheet templates management engine 1106 facilitatesthe creation, editing, or deletion of termsheet templates, which arestored in a termsheet templates database 1108. The termsheet templatesmanagement engine 1106 may make use of terms and rules that are managedin a manner that is described later. The termsheets management engine1106 may also make use of a collaborative rankings engine to obtain datathat may affect various terms either automatically or provideinformation that facilitates intelligent manual termsheet templatemodification based on, for example, attribute rankings.

In the example of FIG. 11, the flowchart 1100 continues to decisionpoint 1114 where it is determined whether the management process is done(presumably for a given session). If it is determined that themanagement process is done (1114-Y), then the flowchart 1100 ends. If,on the other hand, it is determined that the management process is notdone (1114-N), then the flowchart 1100 returns to decision point 1104,and continues as described previously.

Returning once again to decision point 1104, if it is determined not tomanage a termsheet template (1104-N), then the flowchart 1100 continuesto decision point 1114 where it is determined whether to manage atermsheet rule. If it is determined to manage a termsheet rule (1114-Y),then the flowchart 1100 continues to a termsheet rules management engine1118, then returns to decision point 1104 and continues as describedpreviously. The termsheet rules management engine 1118 facilitatescreating, editing, and deleting rules in the termsheet rules database1110.

When creating a rule, an attribute or group of attributes is selectedfrom any applicable place in the system for association with the rule.Examples of engines from which applicable attributes are likely to befound include a student venture application management engine, acollaborative student venture ranking engine, or a student venture duediligence engine (see, e.g., FIG. 6). A rule trigger, such as by way ofexample but not limitation, an if/then/else rule trigger, a numericvalue range of attribute trigger, a top/bottom % rule trigger, anabove/below rule trigger, a unique formula rule trigger, or some otherapplicable rule trigger, is selected for association with the rule.Optionally, the rule can be associated with a specific set of terms.Thus, the termsheet rules database 1110 and the termsheet terms database1112 can have some overlap and/or redundancy. The rule is saved to thetermsheet rules database 1110.

If, on the other hand, it is determined not to manage a termsheet rule(1116-N), then the flowchart 1100 continues to a termsheet termsmanagement engine 1120, then returns to decision point 1114 andcontinues as described previously. The termsheet terms management engine1120 facilitates adding, editing, and removing terms in the termsheetterms database 1112. When creating a term, the term is typically given aname and text (including optional variables) is associated with theterm. Other possibilities include defining in association with the terminter-term dependencies triggered by rules, associating conditions (orrules) with a specific set of terms, and addition conditions (or rules)that cause the term to express itself in a termsheet. The term can besaved in the termsheet terms database 1112. When editing a term, anyvalue associated with the term can likely be changed.

The termsheet templates database 1108, a termsheet rules database 1110,and a termsheet terms database 1112 may be referred to collectively as atermsheet master database (not shown). A termsheet modification engine(see, e.g., FIG. 10) can use the termsheet master database to create atermsheet for a student venture.

FIG. 12 depicts a flowchart 1200 of a venture scholar networking method,such as could be implemented by a venture scholar networking engine(see, e.g., FIG. 5). In the example of FIG. 12, the flowchart 1200starts with an authentication engine 1202. The authentication engine1202 is responsible for largely configuration-related procedures thatensure only appropriately qualified users can have access to networking.Appropriate users may be those who wish to advertise student venturejobs, find student venture scholarships, seek help from peers, experts,and/or mentors, etc. Since at least part of the purpose of thenetworking engine is to provide knowledge to those who are curious, itmay be desirable to make authentication relatively easy (e.g., allow newusers to create “guest” accounts or the like). Certain procedures, suchas posting student venture jobs, may only be applicable to morecarefully vetted users. The authentication engine 1202 can, for example,register, authenticate, verify username/password, etc.

In the example of FIG. 12, the flowchart 1200 continues to decisionpoint 1204 where it is determined whether a user is interested in jobmatching. If it is determined that the user is interested in jobmatching (1204-Y), then the flowchart 1200 continues to a job matchingengine 1206. The job matching engine 1206 can facilitate posting a jobto a student venture jobs database 1208 or querying the student venturejobs database 1208 for a job. In this way, jobs can be posted by userswho need to find venture scholars to join a student venture, and jobscan be found by venture scholars who want to join those studentventures. This can be advantageous in team building, since a team may belacking some critical aspect that could improve the odds of success inattracting the interest of investors and/or succeeding in the studentventure.

In the example of FIG. 12, the flowchart 1200 continues to decisionpoint 1210 where it is determined whether the user is done using theventure scholar network. If the user is done (1210-Y), then theflowchart 1200 ends. If, on the other hand, the user is not done(1210-N), then the flowchart 1200 returns to decision point 1204.

At decision point 1204, if it is determined that the user is notinterested in job matching (1204-N), then the flowchart 1200 continuesto decision point 1212 where it is determined whether the user isinterested in building a personal network. If it is determined that theuser is interested in building a personal network (1212-Y), then theflowchart 1200 continues to a network building engine 1214, then returnsto decision point 1210 and continues as described previously. Thenetwork building engine 1214 can facilitate adding friends, peers,and/or mentors to a personal network. Depending upon the implementationand/or configuration, a user may be able to establish a presence (e.g.,a web page) within a venture scholar network.

If it is determined that the user is not interested in building apersonal network (1212-N), then the flowchart 1200 continues to a socialnetworking engine 1216, then returns to decision point 1210 andcontinues as described previously. The social networking engine 1216 canfacilitate posting questions, announcements, comments, or other posts ona venture scholar network, and searching, browsing, or otherwiseaccessing such posts. In this way, venture scholars or potential venturescholars can obtain peer help, interact with mentors, experts, and/orother individuals, or utilize software programs available on thenetwork.

FIG. 13 depicts a flowchart 1300 of a venture scholar portfoliomanagement method, such as could be implemented by a venture scholarportfolio management engine (see, e.g., FIG. 5). In the example of FIG.13, the flowchart 1300 starts with an authentication engine 1302. Theauthentication engine 1302 is responsible for largelyconfiguration-related procedures that ensure only appropriatelyqualified users can have access to networking Appropriate users may bethose who wish to find mentors for student ventures or monitormilestones, performance, and/or fund disbursements associate withstudent ventures. The authentication engine 1302 can, for example,register, authenticate, verify username/password, etc.

In the example of FIG. 13, the flowchart 1300 continues to decisionpoint 1304 where it is determined whether a user is interested in mentormatching. If it is determined that the user is interested in mentormatching (1304-Y), then the flowchart 1300 continues to a mentormatching engine 1306. The mentor matching engine 1306 can facilitateposting a bio to a mentors database 1308 or querying the mentorsdatabase 1308 to find a mentor. In this way, bios can be posted by usersor for individuals who wish to act as mentors, and a mentor can be foundby venture scholars who want one of the mentors associated with a bio inthe mentors database 1308. This can be advantageous in augmenting a teamthat has a weakness ameliorated by the skills of a particular mentor.

In the example of FIG. 13, the flowchart 1300 continues to decisionpoint 1310 where it is determined whether the user is done managing theventure scholar portfolio. If the user is done (1310-Y), then theflowchart 1300 ends. If, on the other hand, the user is not done(1310-N), then the flowchart 1300 returns to decision point 1304.

At decision point 1304, if it is determined that the user is notinterested in mentor matching (1304-N), then the flowchart 1300continues to decision point 1312 where it is determined whether the useris a venture scholar. If it is determined that the user is a venturescholar (1312-Y), then the flowchart 1300 continues to a venture scholarportfolio management engine 1314, then returns to decision point 1310and continues as described previously. The venture scholar portfoliomanagement engine 1314 can facilitate receipt of alerts or messagesassociated with a student venture, updating contact information or otherventure scholar information, reviewing milestones, performance, funding,etc. that is available to venture scholars. The amount of data that isprovided to venture scholars can vary depending upon implementation orconfiguration.

If it is determined that the user is not a venture scholar (1312-N),then the flowchart 1300 continues to a fund disbursement engine 1316,then returns to decision point 1310 and continues as describedpreviously. The fund disbursement engine 1316 can facilitate receipt ofdata, such as investment info. The investment info can be provided perventure scholar or for the team, or per year, phase, milestone, etc. Thefund disbursement engine 1316 can also automatically trigger paymentwhen milestones are met (though a maximum term or other limitation canpreempt a trigger), or prompt a partner to consider fund disbursementsfor meeting a milestone. The fund disbursement engine 1316 can also exita fund or prompt relevant parties to re-evaluate the deal when a maximumterm is reached or when milestones are not met. The venture scholarportfolio management engine 1314 may or may not have access to this typeof data for venture scholars. A fund resource management engine may beuseful when used in conjunction with (before, during, or after) funddisbursements.

FIG. 14 depicts a flowchart 1400 of a student venture fund operationsmethod, such as could be implemented by a student venture fundoperations engine (see, e.g., FIG. 5). In the example of FIG. 14, theflowchart 1400 starts with an authentication engine 1402. Theauthentication engine 1402 is responsible for largelyconfiguration-related procedures that ensure only appropriatelyqualified users can have access to fund operations. Appropriate usersmay be, for example, partners or advisors. The authentication engine1402 can, for example, register, authenticate, verify username/password,etc.

In the example of FIG. 14, the flowchart 1400 continues to fund datainput engine 1404. The fund data input engine 1404 facilitates entry ofdata for a fund dedicated to student ventures. Such data can include,for example, fund size, fund fees, G&A expenses actuals, space/labcapacity, etc.

In the example of FIG. 14, the flowchart 1400 continues to studentventure data input engine 1406. The student venture data input engine1406 facilitates entry of data for one or more specific studentventures. Such data can include, for example, team data (e.g., number ofmembers on the team, tuition fee and stipends per member, multiple ofseed to invest for follow on, etc.), length of the program, or otherstudent venture-specific data.

In the example of FIG. 14, the flowchart 1400 continues to algorithmicand statistical analysis engine 1408. The algorithmic and statisticalanalysis engine 1408 facilitates calculation of, for example, seedinvestment per person and/or per team, total fellowship cost, successrate, cumulative students/teams active in fund, analysis for additionalinvestments by capital layout and capacity to be used if additionalcapacity exists or becomes available. If additional capacity exists orbecomes available, then an investment decision also exists, and it maybe desirable to utilize a student venture investment decision engine(see, e.g., FIG. 5) to select an appropriate investment vehicle.

Other fund or LP management utilities can include various reports anddisplays (e.g., dashboards), the ability to call for and place capital,alerts, IRR auto calculators on returns, direct investment vehicles fordouble-dipping, etc. University endowment LPs might be given access toadditional utilities, such as university real-time ecosystem calculators(receiving input from, for example, venture scholarship statisticsmonitors, student jobs created statistics, scholarship expense offsets,venture scholar alumni giving trackers, etc.), classroom reportingengines (e.g., grades determine eligibility and teachers can communicatewith LPs), cash and scholarship commitment managers, eligibility alerts,etc. Partners might be given access to utilities that can includegenerating reports specific to a fund or across funds, modifyingdashboard access for an LP, making capital calls, reporting liquidityevents, returning capital in appropriate proportion according toinvestment agreements, soliciting fund placement for new funds, doubledipping management (e.g., as investments mature and approach liquidityevents select LPs can be allowed to deploy capital directly into asuccessful venture to maximize upside).

Other utilities might include document managers capable of storingvarious documents in associations with the various engines and databasesused to implement the techniques described in this paper. This caninclude third party resource managers.

Other utilities might include CRM (VC/LP/C×O) or affiliate managers.This can include contact database management, synchronization and importengines for contacts and correspondence or files, affiliate rules (e.g.,auto renewal, license term length, click to request payment, royalty feecalculators, etc.), and the like.

A computing system representative of computing systems described in thispaper can include a processor, a communications interface, memory, adisplay controller, non-volatile storage, and an I/O controller. Acomputing system can be coupled to or include I/O devices, includingdisplay devices. The device interfaces to external systems through thecommunications interface. A typical computer system will usually includeat least a processor, memory, and a bus coupling the memory to theprocessor. One of skill in the art will immediately recognize that theterms “machine-readable medium” or “computer-readable medium” includesany type of storage device that is accessible by a processor.

A computer system is often controlled by operating system software whichincludes a file management system, such as a disk operating system,which is part of the operating system software. The file managementsystem is typically stored in non-volatile storage and causes theprocessor to execute the various acts required by the operating systemto input and output data and to store data in memory, including storingfiles on the non-volatile storage.

Some portions of the detailed description are presented in terms ofalgorithms and symbolic representations of operations on data bitswithin a computer memory. These algorithmic descriptions andrepresentations are the means used by those skilled in the dataprocessing arts to most effectively convey the substance of their workto others skilled in the art. An algorithm is here, and generally,conceived to be a self-consistent sequence of operations leading to adesired result. The operations are those requiring physicalmanipulations of physical quantities. Usually, though not necessarily,these quantities take the form of electrical or magnetic signals capableof being stored, transferred, combined, compared, and otherwisemanipulated. It has proven convenient at times, principally for reasonsof common usage, to refer to these signals as bits, values, elements,symbols, characters, terms, numbers, or the like.

It should be borne in mind, however, that all of these and similar termsare to be associated with the appropriate physical quantities and aremerely convenient labels applied to these quantities. Unlessspecifically stated otherwise as apparent from the following discussion,it is Appreciated that throughout the description, discussions utilizingterms such as “processing” or “computing” or “calculating” or“determining” or “displaying” or the like, refer to the action andprocesses of a computer system, or similar electronic computing device,that manipulates and transforms data represented as physical(electronic) quantities within the computer system's registers andmemories into other data similarly represented as physical quantitieswithin the computer system memories or registers or other suchinformation storage, transmission or display devices.

The present example also relates to apparatus for performing theoperations herein. This apparatus may be specially constructed for therequired purposes, or it may comprise a general purpose computerselectively activated or reconfigured by a computer program stored inthe computer. Such a computer program may be stored in a computerreadable storage medium, such as, but is not limited to, read-onlymemories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, flashmemory, magnetic or optical cards, any type of disk including floppydisks, optical disks, CD-ROMs, and magnetic-optical disks, or any typeof media suitable for storing electronic instructions, and each coupledto a computer system bus.

The algorithms and displays presented herein are not inherently relatedto any particular computer or other apparatus. Various general purposesystems may be used with programs in accordance with the teachingsherein, or it may prove convenient to construct more specializedapparatus to perform the required method steps. The required structurefor a variety of these systems will appear from the description below.In addition, the present example is not described with reference to anyparticular programming language, and various examples may thus beimplemented using a variety of programming languages.

We claim:
 1. A method comprising: receiving authentication informationfor a team leader at an authentication engine; storing a venturescholarship application data structure in a new applications data store;storing credentials of the team leader in association with the venturescholarship application data structure; building a student venture teamat a venture scholar networking engine; storing credentials of membersof the student venture team in association with the venture scholarshipapplication data structure; allocating financial support associated withthe venture scholarship after the venture scholarship is indicated to beeligible by an eligibility filtering engine; recording equity or aninstrument convertible to equity in a student venture associated withthe student venture team and the venture scholarship at a studentventure fund operations engine; allocating equity or the instrumentconvertible to equity from the student venture to members working on thestudent venture as the student venture matures.
 2. The method of claim1, further comprising inviting people to join the student venture team.3. The method of claim 1, wherein the credentials of members of thestudent venture team include grade point average (GPA), academic major,and mentor.
 4. The method of claim 1, wherein the equity comprises anownership stake in the student venture.
 5. The method of claim 1,wherein the instrument convertible to equity comprises an option topurchase an ownership stake in the student venture.
 6. The method ofclaim 1, wherein the financial support comprises at least a portion of ascholarship or at least a portion of a student loan.
 7. The method ofclaim 1, wherein the equity or instrument convertible to equity isallocated equally to each of the members working on the student venture.8. The method of claim 1, wherein the student venture team comprises auniversity venture team associated with a university, a college ventureteam associated with a college, a high school venture team associatedwith a high school, a community college venture team associated with acommunity college, or a technical school venture team associated with atechnical school.
 9. A system comprising: an authentication engine; anew applications data store coupled to the authentication engine; aventure scholar networking engine coupled to the authentication engine;an eligibility filtering engine coupled to the venture scholarnetworking engine; a student venture fund operations engine coupled tothe eligibility filtering engine; wherein, in operation: theauthentication engine receives authentication information for a teamleader; the venture scholar networking engine builds a student ventureteam; the new application data store stores credentials of the teamleader in a venture scholarship application data structure, and storescredentials of members of the student venture team in the venturescholarship application data structure; the eligibility filtering engineallocates financial support associated with the venture scholarship; thestudent venture fund operations engine records equity or an instrumentconvertible to equity in a student venture associated with the studentventure team and the venture scholarship, and allocates equity or aninstrument convertible to equity from the student venture to membersworking on the student venture as the student venture matures.
 10. Thesystem of claim 8, further comprising inviting people to join thestudent venture team.
 11. The system of claim 8, wherein the credentialsof members of the student venture team include grade point average(GPA), academic major, and mentor.
 12. The system of claim 8, furthercomprising inviting people to join the student venture team.
 13. Thesystem of claim 8, wherein the credentials of members of the studentventure team include grade point average (GPA), academic major, andmentor.
 14. The system of claim 8, wherein the equity comprises anownership stake in the student venture.
 15. The system of claim 8,wherein the instrument convertible to equity comprises an option topurchase an ownership stake in the student venture.
 16. The system ofclaim 8, wherein the financial support comprises at least a portion of ascholarship or at least a portion of a student loan.
 17. The system ofclaim 8, wherein the equity or instrument convertible to equity isallocated equally to each of the members working on the student venture.18. The system of claim 8, wherein the student venture team comprises auniversity venture team associated with a university, a college ventureteam associated with a college, a high school venture team associatedwith a high school, a community college venture team associated with acommunity college, or a technical school venture team associated with atechnical school.
 19. A system comprising: means for receivingauthentication information for a team leader at an authenticationengine; means for storing a venture scholarship application datastructure in a new applications data store; means for storingcredentials of the team leader in association with the venturescholarship application data structure; means for building a studentventure team at a venture scholar networking engine; means for storingcredentials of members of the student venture team in association withthe venture scholarship application data structure; means for allocatingfinancial support associated with the venture scholarship after theventure scholarship is indicated to be eligible by an eligibilityfiltering engine; means for recording equity or an instrumentconvertible to equity in a student venture associated with the studentventure team and the venture scholarship at a student venture fundoperations engine; means for allocating equity or an instrumentconvertible to equity from the student venture to members working on thestudent venture as the student venture matures.
 20. The system of claim19, further comprising inviting people to join the student venture team.21. The system of claim 19, wherein the credentials of members of thestudent venture team include grade point average (GPA), academic major,and mentor.